A “model” may be thought of as a description of a complex application artifact (e.g., business processes, data structures, structure and behavior of software systems, etc.) that is not given in an informal fashion, but rather uses the modeling primitives and conventions of a well-defined “abstract language,” namely, a so-called metamodel. Some common metamodels include the UML family of modeling languages (e.g., UML class diagrams, UML collaboration diagrams, etc.), the BPMN metamodel, the ARIS family of modeling languages (EPC, VAC, FAD, etc.), the entity-relationship (meta)model (ERM), the relational (meta)model, etc. A metamodel, being an abstract language, itself is a collection of modeling elements that may be used or “instantiated” to describe the actual models. For example, in a UML class diagram, the modeling elements are classes, associations, properties, etc., while the model elements in the relational model are relations and their attributes.
A metamodel in principle is independent of concrete notation (and thus was referred to as an “abstract language” above) as, as such, may be thought of as defining only of the language concepts and the rules for their use to form a valid model for this metamodel. Of course, to do actual modeling with a metamodel, a concrete notation is used. For example, the boxes with three “compartments” represent UML classes, labeled rectangles and diamonds are used to represent entities and relationships in the ERM, etc.
A trait common to many metamodels is that its corresponding models may be represented as a graph including nodes and edges that together may be referred to as the graph's “elements.” Software systems handling different “kinds” of models (for example, so-called model management systems) often use some kind of graph model as internal representation for all kinds of models.
Model merging involves creating a single merged result model C from two models A and B (where A, B, and C are expressed in the same metamodel) that describes the same or overlapping sets of application artifacts (e.g., the same software system, the same business process, etc.), but describes these artifacts more or less differently. For example, A and B could be two versions of the same original model that were modified independently, or describe not exactly the same aspect of the application domain with an overlap in some parts.
A merge oftentimes ideally delivers a merged model C that does not contain any redundancies, e.g., such that all model elements that appear in both A and B appear at most once in C. Depending on the exact purpose of C, it often is desirable to preserve all elements that are either in A or B (e.g., to not lose any information from the input models). However, this typically is not a general requirement. Further, it would be desirable to make C consistent and well-formed such that it fulfills all constraints of its respective metamodel.
Because models are a kind of graphs, model merging is a very different challenge than the more ubiquitous (usually line-wise) merging of text files as it is done, e.g., in version control systems. Naturally, text-based merging of models is possible if there is a textual (e.g., XML-based) notation for respective metamodels. However, text-based merge tools are not natural tools for handling the merging of models. First, most textual representations are ill-suited for direct use by humans, and instead are intended to be used as storage formats and/or to be used in model interchange. In particular, the structure of (linear) textual representations usually differs considerably from the non-linear, graph-like structure of the model itself, thereby making it cumbersome to work directly with these representations. Second, even small changes of a model may lead to significant changes of its textual representation, making it hard to differentiate between the actual changes on the model level and purely “syntactical” changes necessitated by the textual representation. Text-based tools therefore are viewed as being inappropriate for model merging.
The merging of two models A and B involves a method for identifying pairs of elements ai and bj from A and B, respectively, which are considered identical and thus are those elements that, after a successful merge operation, appear only once in the resulting merged model C. As used herein, “identical” element pairs are provided as a mapping relation mapAB: A×B.
It will be appreciated that mapAB, being a relation, does not need to be an injective and does not need to be a surjective or even a function in that, in general, model elements from A need not have counterparts in B and vice versa, and an element ai from A could possibly have several “identical” elements bi1, . . . bin in B and vice versa. Methods for producing such a mapAB from two models A and B sometimes are called schema or model matching. In other scenarios, such a mapAB may also result from the process that created models A and B.
Based on the content of mapAB, it is possible to distinguish different categories of (pairs of, groups of, or individual) objects from A and B:    1. If two objects aiεA and bjεB are identified as identical by mapAB (i.e., (ai,bj)εmapAB), and if no other entries involving ai or bj exist in mapAB a (ax s.t. (ax,bj)εmapAB by s.t. (ai,by)εmapAB) and if ai and bj agree on all properties that are relevant for the merge method (e.g., certain attributes etc.), ai and bj are called equal. If ai and bj differ in some of their merge-relevant properties, these objects are referred to as changed.    2. Objects aiεA (bjεB, resp.) for which there exists no object bjεεB (aiεA, resp.) such that (ai,bj)εmapAB (bjεB s.t. (ai,bj)εmapAB) (ai s.t. (ai,bj)εmapAB, resp.) are called added in A (and added in B, respectively).    3. If two objects aiεA and bjεB are identified as identical by mapAB (i.e., (ai,bj)εmapAB), and if other entries involving ai or bj exist in mapAB ((ax s.t. (ax,bj)εmapAB (by s.t. (ai,by)εmapAB), such objects are referred to as conflicting.
With this information, a merge method now attempts to create a consistent result model C. While the handling of objects that are equal is trivial, for all other kinds of objects, decisions have to be made if and how to accept them into the result model C. These decisions depend on the intended purpose of C, the details of the conflicts, the context in which A and B were created, etc. These considerations illustrate that model merging is inevitably a manual task of which only certain trivial tasks can be safely automated. Thus, in general, a human decides which elements and which properties to take from A and which from B for inclusion in the result C. As will become clear from the detailed description below, certain example embodiments described herein relate to improved techniques that support the user with this task, e.g., in the context of the ARIS model transformation component.
The ARIS model transformation component allows one to declaratively describe how models of one type can be transformed into a semantically related model of a different (or sometimes also the same) model type. An example for such a transformation is shown in FIG. 1. In FIG. 1, an example business process modeled using the event process chain (EPC) metamodel is transformed into an equivalent process in the Business Process Model and Notation (BPMN) metamodel. This transformation is referred to as the EPC-2-BPMN transformation. While the EPC metamodel is meant to be used by business-oriented users to capture business processes as they are (or should be) handled in an organization, BPMN is a metamodel and notation that also covers more technical aspects. Using the EPC-2-BPMN transformation, a BPMN may be created from an EPC to be used as starting point to enrich the business view of a process with technical details to ultimately make the process executable by a suitable runtime environment such as, for example, a workflow management system (WfMS).
The description of the transformation is given by so-called transformation patterns, which specify how individual or groups of elements of the source model type are to be translated into corresponding elements of the target model type. The ARIS model transformation and, in particular, the graphical way to describe transformation patterns, is disclosed in commonly assigned U.S. Patent Application No. 61/071,255, entitled “Systems and Methods for Graphically Developing Rules for Transforming Models Between Description Notations.”
In the context of the model transformation, the situation often occurs that after the creation of the initial transformed model T via a transformation run, the source model S is changed by a business user, yielding a modified source model S′. This scenario is illustrated in FIG. 2. To get these changes to the technical BPMN layer, it is possible to simply transform S′ again, yielding a new transformed model T′. However, in the meantime, a process engineer might have modified the original BPMN model T and augmented it with technical information, thereby yielding a modified BPMN model T″. In this case, it might not be possible to simply replace T″ with T′ to get the business-level changes to the technical level, as doing so would risk losing some or all of the changes by the technical user that yielded T″ in the first place. Unless either T′ or T″ can be discarded as a whole and only the changes from T″ or T′ are to be taken into the result, a way is needed to combine the independent changes in T′ and T″ into a single, consistent merged model TM by merging these two models T′ and T″. In this merge process, T′ (the model resulting from transforming the modified source model S′) is referred to as the new transformed model, and T″ is referred to as the merge target model.
FIG. 2 demonstrates conflicts related to the independent modifications to the source model and the transformed model. More particularly, in the FIG. 2 example, the business user added a function F3 to the process as an (exclusive) alternative to F2 to create S′. In the original transformed model T, the process engineer added an additional task F2b to create T″. F2b could represent a task that is necessary from a technical standpoint, but need not be reflected on the business level, for instance. When S′ is now transformed to obtain T′, it can be seen that T′ and T″ differ and that a merge needs to be performed to obtain a result that reflects the changes in both models as good as possible.
As mentioned above in connection with the general model merge problem, to be able to successfully merge the two models T′ and T″, it would be desirable to provide a way to identify elements that are to be considered “identical” for the purpose of merging, e.g., a way to obtain a mapT′T″. Instead of using fuzzy methods like guessing at identical objects based on their properties (e.g., name, type, etc.), or even leaving the identification of pairs of identical objects completely to the user, the transformation itself may place “trace” information on all elements that it creates. This trace information may contain for each element ti in the transformed model, among other things, information about the source element(s) in model S that were “responsible” for the creation of ti, which transformation patterns were involved in the creation of ti, etc. Two objects t′εT′, t″εT″ may be considered to be identical (and thus will be found in a tuple of mapT′T″) if they agree to a certain degree in their trace information and some additional properties. Although the exact implementation details may vary, it will be appreciated that the trace information allows one to obtain the mapT′T″.
In the existing implementation of the model merge in the scope of the ARIS model transformation, the transforming of S′ into T′ and merging T′ with the merge target model T″ with T′ is an integral process. The user picks the source model and the merge target model, and is then presented a single model that illustrates the conflicts between T′ and T″. This model is referred to as the conflict model TC, and FIG. 3 illustrates a conflict model used as a user interface paradigm to perform interactive conflict resolution. In the conflict model, the user may resolve the remaining conflicts to create the final merge model TM. Conflicts may be indicated with graphical icons next to the conflicting elements. These icons sometimes are referred to as the element's “merge state.”
With the mapT′T″ obtained via the transformation's trace information as discussed above, the conflict model is created as follows.
Pairs of elements aεT′ and bεT″ that are identical or changed are shown only once in the result, like the functions F1 and F2, the start and end events, the lanes and the pool in the FIG. 3 example. These elements have no conflicts or “merge state” associated with them. It will be appreciated that in the current implementation, any attribute changes that occurred in S′ are simply written into the existing objects such that the source model silently overwrites any attribute changes in the target. Thus, for the purpose of the merge in the ARIS model transformation, equal and changed objects (as described above) are handled identically.
Elements that are found in T′ but have no counterpart in T″ (according to mapT′T″) are added to the conflict model and flagged with the merge state “added by transformation” (or “added in source”), indicated by a green plus icon next to these elements. In the FIG. 3 example, the BPMN gateway created from the new XOR rule, the task F3 created from the new function F3, and the new “End 2” end event are marked as such, as are all connections between them. Further, the connection between task F2 and the end event “End” is marked with “added by transformation.” Although the corresponding connection has not been changed from S to S′, the reason for this merge state is that the corresponding connection in T″ had been deleted when F2b was inserted by the process engineer. In a perfect world, the actual merge state of this connection would have to be “deleted in target.” The merge, however, cannot distinguish between these two situations. That is, to be able to correctly flag this connection as “deleted in target,” it would be necessary to preserve the complete change history of T′.
For elements that are found in T″ and have no counterpart in T′, two situations can be differentiated. If an element t was created by the (original) transformation (which can be determined based on the presence of trace info on t), this indicates that the source model S′ has changed in a way that an object corresponding to t is no longer created by the current transformation. Consequently, it is added to the conflict model and it is flagged with the merge state “deleted by transformation,” as indicated by a red minus icon. In the FIG. 3 example, the connection between F1 and F2 that was in the original T and was preserved by the process engineer when creating T″ is marked as such, because the connection no longer exists in T′, since the corresponding connection in the EPC has been deleted by the business user when going from S to S′.
If an element t was manually added to T″, which is recognized by the absence of trace information, it also is added to the conflict model and flagged with the merge state “added in target,” indicated by a blue plus icon. In the FIG. 3 example, the function F2b and incident connections are marked as such.
Each element that has one of the three merge states is referred to as an atomic conflict.
All atomic conflicts in the conflict model are listed in a table shown below the model, as illustrated in FIG. 4, which is simply an example conflict table. “Inserted” corresponds to “added by transformation,” “deleted” corresponds to “deleted by transformation,” and “changed” corresponds to “added in target model. The FIG. 4 example table shows additional atomic conflicts pertaining to model elements that have no visual counterpart in the conflict model including, for example, the “belongs to” connections. A connection of type “belongs to” is an example for a container connection. Container connections are used in ARIS models to connect an object to its container object (e.g., from a task to its containing lane, from a lane to its containing pool, etc.), thereby expressing that an object is part of a container instead of relying solely on object dimensions and positioning to express the containment relationship.
Via the FIG. 4 example table, the user may individually accept and reject individual atomic conflicts. When accepting an “added by transformation” or “added in target model” conflict, the corresponding model element is retained and the merge state is removed, thereby indicating that the conflict has been resolved. When rejecting such a conflict, the model element is deleted. When accepting a “deleted by transformation” conflict, the element is deleted. When rejecting it, the element is retained and the merge state is removed.
Aside of the existing merge functionality in the ARIS model transformation component, ARIS offers an XML-based import and export mechanism to transfer ARIS models between different ARIS databases and thus includes the ARIS model merge component. For example, a model M is created in DB X, exported to a file, and imported into DB Y. Assume that model M is now changed in X, yielding a modified model M′, and at the same time, the originally imported model M is also changed independently in DB Y, yielding model M″. M′ is now exported again into an XML file, and imported into DB Y. Because M′ and M″ are different versions of the same model (a fact that is recognized via unique identifiers on the model and all its model elements), a model merge must be performed. When importing M′, the user may select whether or not model M′ (setting “source overwrites target”) or model M″ (setting “target preserved”) will “win” in case of conflicts. These settings may be set differently for objects, connections, and models. However, this merge does not offer selective control over how individual conflicts are resolved and is not interactive.
Oracle's Business Process Analysis Suite offers a model merge functionality (named “process differences”) in the context of their handling of BPEL models. The merge functionality does not use a single conflict model as the merge in the ARIS model transformation, but instead shows the two models that are to be merged side-by-side and highlights the differences in each of the models. Based on the current selections on the differences in the two models, in a third section of the screen, the current state of the merged model is shown. The actual differences recognized by the Oracle BPA merge component closely correspond to the “atomic differences” identified by the ARIS transformation merge functionality discussed above.
The inventor of the instant application has found the individual selecting and manual accepting or rejecting of the model elements that could not be merged (i.e., that have no corresponding element in the other model and therefore have a merge state) to be very tedious and error prone, especially if the models are large and have many differences. For example, objects that have different merge states and are actually the result of one large change in A or B can be “far apart” from each other in the partially merged model and are therefore difficult to find and resolve consistently.
IBM Rational Software Architect (IRSA) is an integrated development environment (IDE) building on the Eclipse platform. On top of the basic functionality of the free Eclipse IDE, it adds features for modeling software design artifacts using diagrams of the UML family of metamodels. Inherited from Eclipse, it offers the basic text-based comparison of files. However, as discussed above, the comparison of complex design artifacts like models in a text-based representation is generally inadequate for the task at hand. Therefore, IRSA offers a model comparison and merging functionality.
In the ARIS world, the term “model” is basically used synonymously with “diagram.” However, a “model” in IRSA is an entire set of diagrams and all model elements, whether or not these elements are actually currently shown in a model. Therefore, an IRSA model roughly compares to an ARIS database.
In the IRSA comparison/merge functionality, the two models being compared and/or merged are shown in a split view, similar to the one offered by the Oracle BPA suite. The models themselves may be displayed in their graphical representation or in a tree representation that is based on the internal structure of the models. To understand this tree, one has to know that the UML models in IRSA are implemented using the Eclipse Modeling Framework. Here, containment relationships play a pivotal role. For example, in UML models, and some kinds of models implemented with EMF, the containment structure plays a pivotal role. For example, classes are contained in a UML class diagram. That is, the model element representing a class is connected from the model element representing the “root” of the model with a containment connection. Similarly, a class's properties, fields, and operations are contained in the respective classes, parameters of operations are again contained in the element representing the operation, etc.
The actual differences recognized by IRSA again roughly correspond to the “atomic conflicts” of the ARIS model transformation merge functionality described above, but also may cover differences like modifications of an element's attributes or other properties, which are currently not relevant for the ARIS merge functionality. IRSA does not simply provide a “flat” list of all model elements that were added, deleted, or changed between the two versions of a model being compared, but instead “groups” the individual atomic changes based on this containment structure in a “structural differences” tab. Here, the individual changes are shown in a tree structure within a node representing the respective “parent” or “container.” Assume, for example, a container model called “hw1,” represented in UML 2, and including the “hello world” class that, in turn, includes first and second attributes and first and second operations. In IRSA, deleting the “hello world” class from the container model “hw1,” adding classes “Class1” and “Class2” to the diagram “Diagram1” and to the model “hw1,” while initiating a change operation in the form of renaming the diagram “Diagram1” to “ClassesDiag” would be indicated as follows:
Left Differences                Deleted hello word <Class> from hw1 <Model>.Owned Member        
Differences associated with hw1::ClassesDiag <Diagram>                Added Class1 <Class> to Diagram1 <Diagram>.Children        Added Class2 <Class> to Diagram1 <Diagram>.Children        Changed Diagram1 <Diagram>.Name from “Diagram1” to “ClassesDiag”        
Added Class1 <Class> to hw1 <Model>.Owned Member
Added Class2 <Class> to hw1 <Model>.Owned Member
IRSA now groups the individual atomic changes based on this containment structure, such that it does not simply provide a “flat” list of all model elements that were added, deleted, or changed between the two versions of a model being compared, but instead groups them based on their respective parent/container element. The atomic conflicts may then be accepted either individually or “per container,” on any level of the hierarchy. During the actual model merge, the user may perform “Accept” and “Reject” operations on the individual differences, or on the groups created from the containment relationships.
As indicated above, because of the peculiarities of model merging in general, and because of varying requirements on the merged model, model merging is in general a manual process. Any fully automatic “fire and forget” solution will invariably either have to be optimized for certain use cases where the requirements are well-defined (and can consequently not be generic) or it will yield inadequate results for the majority of usages. It would be desirable to provide a generic model merge tool with practical relevance such that it provides an interactive user interface that allows the user to compare the models being merged and resolve the conflicts.
Prior solutions unfortunately are complex, and conflict resolution on the level of atomic conflicts is error prone. A common drawback of existing interactive merge approaches relates to a limited ability to recognize individual “atomic conflicts” between the two models being merged. Regardless of the actual paradigm used to present these differences (e.g., an integrated “conflict model” as in the case of the ARIS transformation merge, the “split screen” provided by Oracle's BPA suite, etc.), a common problem of these approaches is that even with a relatively modest number of differences between the models being merged, the user is quickly overwhelmed by their sheer number. As the conflict model in the FIG. 3 example and the corresponding table of atomic conflicts in FIG. 4 illustrate, even comparatively small changes lead to a large number of atomic conflicts that require individual attention by the user. For each such element, the user has to decide what to do with it (e.g., remove it, accept it into the merge result, accept it after modification, etc.), requiring a considerable amount of user attention and opening the door to mistakes.
Furthermore, models often have model elements without a direct graphical representation that can be subject of an atomic conflict including, for example, the container connections described above. Because atomic conflicts of these elements are resolved by the user, as well, technical details from which the user typically is shielded during normal modeling become apparent. The model comparison and merge functionality of IRSA discussed above, for example, makes no effort to shield a non-expert user from the details of how the (graphical) diagrams are represented internally and instead exposes these details, both in the tree view of the models under merge and in the “structural differences” tab. In the latter case, these internal details, and the containment relationships in particular, are actually used to group the differences.
While the atomic conflicts within such a group are related by virtue of being in the same container, there is no grouping based on the actual semantics of the high-level editing operations that were performed to go from the one model to the other. For example, while the two add operations for the classes “Class1” and “Class2” from the IRSA example above are shown within one group (and thus have the same parent node in the “structural differences” tree), the actual addition operations are in general not semantically related. They nonetheless could have been performed completely independently of each other. One familiar with the way models and diagrams are represented internally in IRSA will also note that the classes “Class1” and “Class2” that were added to the (renamed) diagram were not added to the model itself. This indicates that the classes themselves are not actually new, but instead indicates that their addition to the diagram is only the creation of new views on these two classes that had already existed in the original version of the model. This information, however, is not made obvious to the user and instead at best is left to conjecture based on the individual differences, thereby requiring in-depth knowledge of the internal workings of the model representation. While the deficits of IRSA can in part be explained by its different target user group (software engineers instead of business analysts), it shows that IRSA does not help in resolving larger, semantically related groups of differences during merging.
Due to the individual accepting or rejecting of atomic conflicts and consequently the individual deletion or preservation of model elements, it is also possible to make a model invalid during an interactive merge. One example of how this might come about involves “invisible” containment connections such as, for example, the “belongs to” connections between tasks and their lanes. Assume that there exists an object whose merge state was “added in target” that is contained in a container, like the function F2b in the FIG. 3 example. The container connection from F2b to the containing lane “Alice” carries the same merge state. During manual conflict resolution, a user might accept the addition of F2b in the target model but might reject the corresponding container connection (perhaps because the user is not aware of how containment is represented in ARIS). Absent precautions in the merge tool that would reduce the likelihood of such a situation from arising, it is entirely possible to produce an inconsistent model.
Thus, it will be appreciated by those skilled in the art that it would be desirable to provide improved interactive model merging techniques.
In certain example embodiments, a method of resolving model merge conflicts is provided. A conflict model based on a merging together of first and second models is generated via at least one processor. At least one high-level conflict based on the conflict model is detected, with the detecting being performed following said generating. A list of the at least one detected high-level conflict is displayed, along with a visual representation of the conflict model. Each said high-level conflict includes a combination of atomic and/or other high-level conflicts, with each said high-level conflict being classified as either (a) a simple high-level conflict that includes as its constituent(s) a plurality of atomic conflicts, or (b) a complex high-level conflict that includes as its constituent(s) at least one other high-level conflict. A user may resolve the at least one detected high-level conflict after the displaying of the list and the visual representation of the conflict model. According to certain example embodiments, the first model may be a merge target model and the second model may be a transformed model, with the transformed model having been generated by applying a model transformation to a source model.
In certain example embodiments, there is provided a non-transitory computer readable storage medium tangibly storing instructions that, when executed by at least one processor of a system, perform a method as described herein.
In certain example embodiments, a system for resolving model merge conflicts is provided. A conflict model generator is configured to generate a conflict model based on a merging together of first and second models, with the merging being performable via a merge engine. A detector is configured to detect high-level conflicts within the conflict model based at least in part on output from the merge engine. A user interface is configured to display a list of detected high-level conflicts, along with a visual representation of the conflict model. The high-level conflict is of a predefined type, includes constituent conflicts, and either is (a) a simple high-level conflict that includes as its constituent(s) a plurality of atomic conflicts, or (b) a complex high-level conflict that includes as its constituent(s) at least one other high-level conflict. The user interface is further programmed to receive user input enabling a user to resolve detected high-level conflicts. According to certain example embodiments, the system may further comprise a model generator programmed to receive user input enabling the user to create models and define transforms for models.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.